Standard Web services architecture
Figure 6–1 shows the basic Web services architecture supported by the industry. This architecture is common to all implementations of Web services.
In Figure 6–1, the set of components required for Web services appear with gray shading. The dashed arrow shows that the WSDL reflects the application server interface, but does not come directly from the application server, itself. The following sections describe how this architecture works and provide more information on the advantages that have increasingly made Web services an industry standard.
Web services client
In general, the typical Web services architecture includes an application acting as the Web services client (as shown by the Progress 4GL client in Figure 6–1). This Web services client is an application that can access one or more Web services, typically using the APIs provided by client interfaces. A Web service client interface simplifies client programming by presenting the Web service interface directly in the native programming language of the client (Progress, Java, .NET, and so on). The API to access this Web service interface is often encapsulated in the client interface as objects designed for the particular client language. Client development platforms either allow you to generate a a complete client interface directly from a given WSDL file or generate complete documentation on how to access and invoke operations in the Web service, further simplifying client development.
For more information on how OpenEdge supports client access to Web services from the Progress 4GL, see the "OpenEdge support for accessing Web services" section.
Run-time process
To invoke a Web service operation, the client application makes a request, which is essentially a remote procedure call, by invoking an operation (method on a client interface object, function, or procedure, as is appropriate for the client language). This operation invocation causes the client to create an industry-standard, SOAP-formatted message, which includes any input or output parameters that the method requires. The client then sends the message, using an HTTP (or HTTPS) Post method, to a Web service provider that hosts (or provides) the Web service.
The Web service provider then normally relies on a Web server (which has an HTTP Listener) to receive the HTTP Post method and pass the client SOAP message to a SOAP processor, which also runs in conjunction with the Web server. The SOAP processor translates the message and passes it to a business interface, which in turn, translates it into a form that can be consumed by an appropriate application server.
The application server that implements the Web service receives the translated message and invokes the operation in the business logic that corresponds to the requested Web service method or procedure. The method or procedure performs some function and returns a result (if only to indicate success or failure) that includes any values returned as output parameters and possibly a return value.
This process reverses itself to return the result (output or return values) to the client. The application server passes a message that includes the output parameter values back to the Business Interface and SOAP processor, which converts it to a SOAP message. The Web server then passes the SOAP message as an HTTP Response to the Web services client where the message is read and interpreted by a client-side SOAP processor as the return or output parameter values from the original Web service method.
Design and development process
At this point, a question remains: How does the client application identify and understand how to invoke the methods and procedures of a particular Web service? This is the function of WSDL, the XML-based industry standard that describes the content and format of SOAP messages used to interact with a particular Web service.
The developer of a Web service typically has design and development tools to automatically generate WSDL files. Thus, they can design and generate a WSDL file that defines the Web service interface to the business logic they have written (or will write) for an application server. The typical developer of a client application also has code generators that can read this WSDL file and automatically generate the code required to construct and parse SOAP messages to access the Web service from within their client application.
Because the WSDL files used to define Web services conform to industry standards, the Web services development platform used to make the application server accessible as a Web service is completely independent from the Web service client development platform. Each platform can thus be provided by different vendors as long as they both generate conforming SOAP messages. This means that if the client developer knows how to read WSDL and the Web service developer knows how to write WSDL, and both have the understanding to generate and interpret compatible SOAP messages, they can each manually write all their own code to (respectively) invoke Web service operations and serve Web service clients. However, as for most programming languages and Internet standards, many available client and Web service development platforms provide tools and code libraries to make Web services programming much more productive.
Application servers
The heart of any Web service is the business logic that runs on an application server (as shown in Figure 6–1). Web service support exists for many existing application server platforms, and new application server platforms dedicated to supporting Web services are also available. Existing server applications can often be packaged as Web services with little or no modification to application code. For example, existing server applications written in Microsoft C# can be supported as C#.NET Web services using ASP.NET. Similarly, Java server applications based on Enterprise Java Beans (EJBs) are often supported as Web services by vendors of Java Servlet Engines (JSEs) using Java servlets to implement both the SOAP processing and interface to the EJB application. Thus, the EJB application might run also as a Java servlet on the Web server, in a separate JVM local to the Web server, or on a separate machine that hosts the application on a network in n-tier fashion.
In all cases, Web services provide some gateway between SOAP and the application server interface (the SOAP processor and business interface shown in Figure 6–1). This gateway translates Web service messages between SOAP and the interface for the business function supported by the server application. Therefore, the OpenEdge Web services tools provide equivalent support to create Web services from both new and existing AppServer applications.
HTTP/S
HyperText Transfer Protocol (HTTP), along with its secure cousin, HTTPS, is the most widely used application-level protocol for transporting remote invocation messages between a Web services client and the Web service provider, typically a Web server or JSE. As such, HTTP/S is the modern telephone line for the communications portion of Web services. It is ubiquitous and meets the basic requirements fulfilled by the telephone line, handling secure communications between Web service clients and providers located anywhere in the world.
Thus, most Web service clients can exchange messages with Web services using a standard HTTP/S Post method and Response. Again, because it is already widely used for secure and nonsecure Internet data communications in a connectionless mode, it is already the prevailing Web services standard, avoiding the need to create a new Web services communications protocol or the client/server technology to support it.
SOAP
Simple Object Access Protocol (SOAP) is an XML-based standard that defines the protocol to format messages exchanged between a Web services client and a Web service. Thus, a SOAP message generally contains one of the following:
SOAP is an open messaging protocol that supports the exchange of data using multiple SOAP message formats (combinations of SOAP communications style and SOAP representation, or use). Depending on the format, SOAP messages pass data using XML schema or a combination of XML schema and a custom encoding. SOAP also supports multiple bindings that use different communications protocols to transport these messages. However, because of the ubiquity of HTTP/S, SOAP over HTTP is the prevailing standard protocol binding for Web services.
Again, SOAP, as a widely available XML standard, allows virtually any existing Web service client technology that can code and decode SOAP to use Web services with no additional support. However, the complexity of human programming is such that most Web service client vendors provide run-time libraries and code generation tools (see the "WSDL" section) to enhance their existing client platforms, making them more Web-service-ready.
Web services client platforms (OpenEdge, Microsoft .NET, Apache AXIS, and so on) and Web Service Providers typically support only a few of the possible SOAP message formats. However, in order for a given client to access a Web service supported by a given Web service provider, the Web service must use a SOAP format that the client supports. Thus, flexible Web service providers support Web services using the SOAP formats that are supported by most Web service clients. For more information on SOAP and the SOAP formats that OpenEdge supports for Web services built in the Progress 4GL as well as Web services accessed by 4GL client applications, see OpenEdge Development: Web Services .
WSDL
WSDL is another XML-based standard that supports typical Web service implementations, and is used to describe Web services to potential Web service clients. A single WSDL file typically defines one Web service and its operations sufficiently to program a client to the specified Web service interface. However, to use this Web service interface in a client application effectively (as with any interface) usually requires documentation in addition to the WSDL definition itself, especially to describe the requirements for data that is input to the interface.
The WSDL standards provide several basic XML elements to define a Web service, including its name, the set of operations that it supports, the data types of parameters on those operations, the SOAP format of the messages used to invoke operations and return their results, and the exact protocol bindings and services that support the Web service; in short, everything that a potential Web services client needs to use the Web service, wherever it is hosted on the Internet.
Theoretically, Web service developers can write their own WSDL file to define a Web service they are building. However, most Web service development vendors provide tools to automatically generate the WSDL file directly from the application server interface and additional information, including the SOAP format and the location of the Web service, to make the Web service available to potential Web service clients. Similarly, most Web service client platform vendors also provide tools to take the WSDL file as input and automatically generate the code for the client interface that the client application calls to invoke operations on the specified Web service.
For more information on WSDL and how OpenEdge uses it to define the client interface for Progress 4GL Web services as well as to define the client interface for industry Web services accessed by Progress 4GL clients, see OpenEdge Development: Web Services .